UniFi, Or The Story Of Unnecessary Cloud Accounts

My own stance on privacy #

From a security and privacy perspective, I consider myself to be a pragmatist. As with a lot of things in life, there are trade-offs between complete security, privacy, convenience, and ease of use. You could go live in the woods, not have an Internet connection, and grow a three-foot beard so that nobody can recognize you. That’s a somewhat guaranteed recipe for complete privacy and security, and unless you’re also worried about satellites photographing your greenwood-shielded compound, you might be a-OK in never having any of your data siphoned off by an adversary. But that is nowhere near practical for the vast majority of the population and you can’t expect even one percent of them to tackle this kind of radical approach to life. So, we end up with trade-offs.

Our trade-offs include managing thermostats through online-based services, so that we can set the temperature in our house before we come from work miles away, even though theoretically a malicious actor could hack into your account and start fiddling with temperature settings. A lot of the electrical meters in the United States have radio components that broadcast electricity usage within a household, meaning that anyone can theoretically scan for how much electricity your house uses with a $25 accessory and some off-the-shelf open-source software. So can the utility company, though, to get an accurate reading without coming to visit every house at the end of the month and look at the digits in-person.

The more we immerse ourselves into the digital-first world, the more these trade-offs become common. And they are different from person to person. I have zero tolerance for advertising in any of my devices and will go above and beyond to block them through any means necessary. A lot of my friends couldn’t care less about this and actually prefer when the ad content they get is personalized. I don’t store any unencrypted content in cloud storage services, while plenty of folks use those to sync their photos, documents, and other more or less private content in the clear because it’s more convenient for them. There is no black and white delineation when it comes to your own privacy and security threat model.

Unlike some of the more popular guides on privacy and security that espouse the virtues of spinning up nine virtual machines for different purposes, using a Faraday bag every time you bring your phone in the proximity of your home, or creating burner emails for every single online transaction, my own goal and that of what I advocate for is not to become invisible but rather have an informed and clear choice on making the right trade-offs that suit the users’ own posture.

Cloud everything #

One of the more prevalent trends with modern technology is that vendors seem to be hell-bent on embedding cloud-related stuff that requires an account where it’s not needed. That’s not to say that there is no value in cloud infrastructure - there absolutely is, and most of us depend on it functioning for us to be able to carry our lives, but not everything needs to be associated with an identity. Some of the more chronically online readers might all of a sudden start getting flashbacks to the content from @InternetOfShit on Twitter (RIP) and the appropriately-named subreddit that capture the spirit of the problem. Who doesn’t want their microwave to lock up and not heat food up because you didn’t connect it to your WiFi for it to validate if your account still has a license to use the hardware? For what it’s worth, I wrote on this very matter a whopping two years ago and yet - not much has changed.

I try to avoid as much of the IoT stuff as possible for the sole reason that a lot of it is as secure as a slice of Swiss cheese (the “S” in IoT stands for “security,” after all), but also almost all of it that is not build on open standards is a means to extract not only the money for the gadget, but also insights about you. The good ol’ Tumblr meme is alive and well in 2023:

Tech Enthusiasts: Everything in my house is wired to the Internet of Things! I control it all from my smartphone! My smart-house is bluetooth enabled and I can give it voice commands via alexa! I love the future!

Programmers / Engineers: The most recent piece of technology I own is a printer from 2004 and I keep a loaded gun ready to shoot it if it ever makes an unexpected noise.

Suffice to say that I am a big fan of self-hosting infrastructure where I can, at least for things as essential as my own networking setup. And if I needed more fuel for this belief, cue to this past week when users of UniFi, a well-known networking gear vendor, discovered that their private footage and network infrastructure was likely exposed to complete strangers. As a UniFi user myself, I wish I was kidding:

I’m reaching out for some advice regarding a peculiar situation we encountered with UniFi Protect. Recently, my wife received a notification from UniFi Protect, which included an image from a security camera. However, here’s the twist - this camera doesn’t belong to us.

And it’s not just private footage from and around your home that might’ve been exposed, but also potentially infrastructure. That is - another user allegedly discovered that they could see network consoles that did not belong to them. If you used UniFi gear before, you know that unauthorized access to a network console is a pretty massive problem. Whoever has access to one or many consoles through the web UI could do a lot of damage, like re-configure networks, look at WiFi passwords, or, you know, look into the browsing habits within the household that are broken down on a per-device basis within UniFi’s network analytics UI. The common thread among these two reports on two different sites? They were both enabled with UniFi’s “Remote Access” functionality through the connected UI account.

Why this is a problem #

Broadly speaking, having data aggregation and management functionality alone is not really cause for alarm. If you deploy networking infrastructure within your house or organization that monitors network usage locally, use cameras that record footage locally - hey, more power to you.

I love looking at analytics myself and have done so since some of the early UniFi days. But do I want some absolute strangers looking at the view outside my home, or see what my network configuration is like, including credentials? Absolutely not!

Yet, because of how UniFi structures their systems, users of their hardware are all but pushed into the “cloud-based” accounts that expose their infrastructure to the web as a convenience. And frankly, a lot of customers likely would find this extremely convenient - after all, no more fiddling with firewalls, open ports, or VPN profiles. You log in with your UI account, and you’re in - from anywhere in the world:

But what if I wanted to make life difficult for myself? What if I do care about GDPR and my own privacy? Tough luck, because having a UI account is the default everywhere.

At least in part the issue is also compounded by the fact that a startling number of UniFi users don’t fully understand the risks of a cloud-connected account up until something happens (and it did this week). Take these conversations on Reddit as an example of how people that deploy UniFi gear think about the entire “UI account needed” requirement:

There is a fundamental gap in understanding here. The account is a “passthrough” in the sense that it exposes your networking gear to the public Internet. Anyone with access to the UI account can access your infrastructure (both networking and cameras) remotely. UI could themselves use the insights they aggregate from your network to sell to other third-parties (I am not aware of this being the case, but what’s to stop them from changing the terms of service later). Anyone with a legal basis (like, say, a subpoena) would theoretically also have access to your infrastructure and the data within that infrastructure, as outlined in Ubiquiti’s own privacy policy (highlights mine):

How We May Disclose Information. We may disclose the information we collect related to the Services as follows:

a. Usage Data. We may provide Usage Data to our customers in connection with the Services which those customers use. For example, our customers may include your network providers or operators and we may disclose Usage Data to these customers in connection with the products and devices that are deployed over these customers’ networks. The treatment of Usage Data by these third-parties is subject to their own privacy policies, and not this one. We are not responsible for the content or privacy and security practices and policies of those third parties.

b. Aggregate or De-identified Data. We may share Non-Personally Identifiable Information, including Usage Data (such as anonymous or aggregate user usage data, referring/exit pages and URLs, platform types, etc.), with certain third-parties to assist such third-parties in understanding the usage patterns for certain content, services and/or functionality with respect to our Services. We may also share aggregate or de-identified information about users with third-parties for marketing, research, or similar purposes.

c. Business Transfers. If we are acquired by or merged with another company, or if substantially all of the assets of one of our business activities are transferred to another company, we may transfer the information we have collected from you to the other company.

d. Third Party Service Providers. We may disclose certain User Information to third party vendors, service providers, contractors or agents (collectively, “Third Party Processors”) who perform functions on our behalf (e.g., vendors that help us with delivering Services to you, maintaining our Sites, providing technical operations such as analytics, database monitoring, data storage and hosting services, providing customer support, analyzing the Services, sending marketing and other communications, or for other legitimate business purposes). You may request the list of Third Party Processors for your Service by contacting us in writing using the contact information in Section 15 below. These Third Party Processors may access, process or store Personally Identifiable Information in the USA and elsewhere in the course of providing these services but based on our instructions only. If we receive Personally Identifiable Information subject to our certification under the EU-US Data Privacy Framework (the “DPF”) and then transfer it to a Third Party Provider acting as an agent on our behalf, we have certain liability under the DPF if both (i) the agent processes the personal data in a manner inconsistent with the DPF and (ii) we are responsible for the event giving rise to the damage.

e. Other Disclosures. We may also disclose User Information (1) if required to do so by law, or in the good-faith belief that such action is in compliance with applicable laws (including, without limitation, copyright laws) or in response to a court order, subpoena, legal process, search warrant or request by a public authority, including to meet national security or law enforcement requirements; (2) if we believe, in good faith, such action is appropriate or necessary to enforce our Terms of Service or any terms applicable to specific Services, exercise our legal rights, take precautions against liability, to investigate and defend ourselves against any claims or allegations, to assist government enforcement agencies, to protect the security or integrity of our Services, and to protect the rights, property, or personal safety of us, our users or others; (3) to any parent company, affiliated entity, or other entity controlled by, controlling, or under common control with, us (in which case, we will require such entities to honor this Policy); or (4) as otherwise described herein.

So, for privacy-minded users, the UI account becomes a liability vector - the trade-off is between convenience of access and your data remaining your own without a third-party having access to it. Passthrough or not, your video and content becomes accessible through a single identification entity, your UI account. Because I don’t want anyone snooping within my infrastructure, I chose to retain the data I own and not expose the gear through a UI account, completely disabling remote access. Were it so easy.

The moment I set up my gear without any UI account associated with it, the mobile applications become effectively useless. UniFi really wants you to use the account if you want to have remote access, even if you’re the one that can manage remote access yourself.

Even aside from the abuse angle, and here is where I put my engineer hat on, building secure and private applications that host or transport user data (in this case - about your infrastructure and visual surroundings) and are shielded from internal and external abuse is extremely hard. It takes a lot of effort to find all potential attack vectors or bugs, patch them in time, and hope that one change didn’t break something in some legacy system in another corner. I am under no illusion that this is trivial - it is not. Users of networking gear especially care about the security, reliability, and robustness of all of the access controls. However, the company has been adamant about pushing people into their cloud-based ecosystem and has actively tried to force every customer to have an account and send telemetry when deploy their devices. They thankfully backtracked on both the account requirement and telemetry for now, but I there is no guarantee that this won’t change in the future.

With this push, it’s important to acknowledge the risks that:

1. Anything you put on the public Internet can (but might not) be abused by uninvolved parties.
2. Anything you connect to an account can (but might not) be abused by the vendor managing the account.
3. Anything connected to an account can (but might not) be tracked, monitored, measured, and analyzed by the account provider.

Now, I am not a total Luddite - we take calculated risks every day in maintaining tens if not hundreds of online accounts for many services, like email, shopping sites, online communities, our smartphones, and much, much more. I am not saying that we should self-host everything and never have an account anywhere. The impact of someone accessing your email is likely as, if not more, catastrophic as someone who would access your internal network setup, so why am I writing this post about the UniFi experience and not, say, Google? Because for certain things an online account is not needed.

I have zero desire to host my own email server because it’s a laborious initiative and I have better things to do than patch my server every day and try to set up home-made spam filters. I do have enough desire to manage my own networking infrastructure in the way that best fits my expectations of it. I should be able to access my infrastructure in a secure and self-managed way, where I can control who and how it can be accessed by. A UI account is not the answer to that for me and I am not alone in this observation.

Where does this lead us #

Stop forcing a UI account for UniFi gear.

I enjoy deploying and hosting UniFi gear. The quality could be better in some cases - in the last year two U6-LR access points units failed in the same way, entering an endless reboot cycle that nothing can get them out of. They were promptly replaced by Ubiquiti’s RMA department, which I am happy with. Their browser-based UI is great, and while the apps could do better, they are light years ahead of their closest competitors. UniFi gear is exactly what I would expect from prosumer networking hardware, giving just the right level of customization at a reasonable price.

But this same hardware starts creeping into “force you into the cloud” territory, which is not for everyone, and shouldn’t be for everyone. One of the reasons why I like the UI gear is because I am not forced into some weird licensing agreement or requirement for an enterprise account that is linked to every single access point. I don’t want to create a UI account to manage my Dream Machine. I do not want to use a UI account to be able to access my cameras remotely. And best of all - this is not actually an ask for any new functionality.

The web experience works just fine over something like Tailscale. The apps, on the other hand, are utterly broken, and in kind of funny ways. If you use a Tasilscale (maybe for OpenVPN it’s different - who knows), you are likely aware that UDP broadcast/multicast is not supported due to how L2 and L3 networks interoperate. Guess who relies on this to discover your local UniFi console that manages the network and cameras? The moment I go remote and try to use the apps via Tailscale, they log me out from my current session and prompt to add a console… which cannot be discovered, because broadcast and multicast traffic is not routed over. And that’s it. I am stuck until I come back home and am able to log in from my local network.

The solution to this is actually fairly simple (and I use that word lightly):

1. Give the user the ability to specify the IP address of the console directly in the app.

That’s it. That’s the solution. When Tailscale-d into my network, I can easily open 192.168.1.1 in the browser, enter my local account credentials, and have access to my network. Why is the same functionality not available in the app? Actually, it is available, but only in the UniFi (the networking arm) app. I can explicitly provide a console IP address, although that functionality is obscured through seven layers of indirection until I got to the right view. After that - the app works marvelously over a Wireguard tunnel. Protect? Not so much. Every time I try to “Proceed without UI account” I get into a neverending “Back to the login screen” loop:

Dear UniFi product managers - if you are reading this, when designing both your software and hardware, for the love of everything, please also account (hah!) for folks who do not want and never will have a UI account. We’re grown adults, we can manage access to our own networks with over-engineered solutions. Just give us a consistent option here, and stop forcing the UI account into everything. I don’t want it.